Virtual Leased Line (VLL) is a service for providing Ethernet based point-to-point communication over Internet Protocol (IP) and Multi-Protocol Label Switching (MPLS) networks, or IP/MPLS networks. This technology is also referred to as Virtual Private Wire Service (VPWS) or Ethernet over MPLS (EoMPLS). VLL service provides a point-to-point connection between two customer edge (CE) routers. It does so by binding two attachment circuits (AC) to a pseudowire that connects two provider edge (PE) routers, wherein each PE router is connected to one of the CE routers via one of the attachment circuits. VLL typically uses pseudowire encapsulation for transporting Ethernet traffic over an MPLS tunnel across an IP/MPLS backbone. More information on pseudowires can be found in “Pseudo Wire Emulation Edge-to-Edge (PWE3) Architecture,” RFC3985, IETF, March 2005, by S. Bryant and P. Pate.
Virtual Private LAN Service (VPLS) is an Ethernet service that effectively implements closed user groups via VPLS instantiations. In order to achieve full isolation between the user groups, VPLS dedicates a separate database, usually in the form of a forwarding information base (FIB), on network routers per VPLS instance. Each VPLS instance further requires that a dedicated mesh of pseudowire tunnels is provisioned between PE routers that are part of the VPLS.
Both VLL and VPLS use service access points (SAPs) to bind tunnel endpoints at PE router ports to their respective services. For example, in the case of VPLS, an SAP would specify physical identifiers (e.g. node, shelf, card, etc.) of the corresponding port and an identifier (e.g. VLAN5) of the VPLS.
Services such as VLL and VPLS provide the capability to securely communicate data packets among routers provisioned with the same service. Typically, thousands of such services are provisioned on a network, the data packet traffic that they each carry being kept separate from one another via special treatment provided at each router on which an instantiation of that service has been provisioned.
Each service has physical characteristics that in part define the service. These characteristics, also referred to a quality of service (QoS) parameters, include constant information rate (CIR), peak information rate (PIR), and maximum burst size (MBS) parameters and are often grouped into a policy for convenient provisioning of a service on a given router.
An SAP provisioned on a router is used to associate a service instance with a port of the router and a policy. An SAP can also associate an override with a policy, wherein a value of one of the QoS parameters is specified to be used instead of the value for that QoS parameter defined by the associated policy.
Although policies and policy overrides are local to a router, it is desirable to define and use them on a network-wide basis for consistency. However, in a large network with thousands of routers, each having dozens of ports, and the even larger number of unique combinations of QoS parameter values that can be defined and assigned to these ports, limitations on the maximum number of policies that a network management system managing the network can support are easily exceeded. Using policy overrides to alleviate this problem only exacerbates difficulties in achieving network-wide consistency in the provisioning of services. Furthermore, since policies and policy overrides can be provisioned both locally at a router and centrally via the network management system, keeping the provisioning of services in synchronization at the network management system and network routers is difficult.
These and other policy-related issues are addressed in U.S. Pat. No. 8,040,822, entitled “Configuring Communication Services Using Policy Groups,” which is commonly assigned herewith and incorporated by reference herein. For example, embodiments disclosed therein provide a means of configuring services on a network in a manner that ameliorates one or more of the aforementioned problems.
Despite the considerable advances disclosed in the above-cited U.S. Pat. No. 8,040,822, a need remains for further improvements in configuring services on communication networks, particularly with regard to management of encryption keys and other aspects of secure services configured on such networks.
For example, traditional encryption on the Internet, such as that provided by Internet Protocol Security (IPsec), a protocol suite for securing IP communications by authenticating and encrypting each IP packet of a communication session, and which also includes protocols for establishing mutual authentication between agents at the beginning of the session and negotiation of cryptographic keys to be used during the session, is intended for providing users with security for sensitive data and applications.
IPsec was designed for authenticating and encrypting IP packets between two routers in a point-to-point fashion by establishing an encryption tunnel between those routers. IPsec was not designed for networks that carry a mix of IP and MPLS traffic for Layer 2 and Layer 3 services or for network level encryption and security between a multitude of routers communicating together.
IPsec is similarly unable to provide network level encryption and security between a large number of routers communicating between one another simultaneously without establishing a full mesh of IPSec tunnels between the routers. Creating full meshes of IPSec tunnels for inter-nodal encrypted traffic is cumbersome and inefficiently uses network and router resources.
Conventional techniques such as IPSec therefore fail to provide adequate management of encryption keys and other aspects of secure services involving encrypted tunnels in a communication network.